1. Field of the Invention
The present invention relates to systems and methods for managing executing program code or modules. More specifically, the invention relates to ways of changing or updating the executing program code or modules without requiring a shutdown and restart of the executing code or otherwise minimizing the performance or downtime impact of updating software.
2. Present State of the Art
There exist high availability computer programs running on very reliable computer systems for many important applications. These systems and programs typically run 24 hours a day, 7 days a week, and any interruption to processing can represent have serious repercussions in terms of customer service and, in some situations, safety.
For example, the advent of electronic commerce over the Internet and World Wide Web requires that e-commerce websites always be available for processing transactions. Other examples include credit card transaction processing applications, air traffic control applications, etc. One example environment where high availability is important that will be used throughout are applications built using the IMS system available from IBM, Corp., Armonk, N.Y.
As software for such critical applications is enhanced xe2x80x9coff-linexe2x80x9d on development environments, it becomes necessary to deploy or refresh such enhanced software xe2x80x9con-linexe2x80x9d into the production environment. Previous ways of deploying such enhancements has required saving state data, shutting down or otherwise impairing the availability of the critical application, installing the new software, and then restarting the application or otherwise making it fully available. At this point, the application would be running the enhanced code with the existing data.
By shutting down the system or other performance impacting event, such as a manual quiescing of the system, service is disrupted. Therefore, there exists a need to apply changes (enhancements and/or maintenance) to one or more modules of software within an actively-running system without requiring a shutdown or interruption of that system. Furthermore, there exists a need to add or delete such modules within an actively-running system.
When updating modules on a running system, the updating would need to preserve state information from previous instances of the changed modules and to provide this information to the new instances of these modules. Furthermore, the need exists to ensure that the refreshing of a set of modules is done atomically (either all are refreshed or none are refreshed).
The IBM OS/390 operating system has a function called Library Look Aside/Virtul Look Aside Facility (LLA/VLF) that manages modules in memory and can refresh the in-storage copies of the modules. However, the modules loaded by LLA/VLF are kept in memory for the purpose of facilitating faster module loading when requested by another address spaces. This is analogous to an in-memory cache of modules that will be requested from more permanent storage. Because the modules are pre-loaded, the request can be quickly serviced. It is important to note that the pre loaded copies of the modules are not themselves executed directly.
As such, while LLA/VLF can refresh modules in storage, it does not also control execution of them by running units of work. Programs using modules managed by LLA/VLF would still have to shutdown and restart to execute updated modules.
One aspect of the present invention allows a set of modules to be dynamically refreshed, added, and deleted in an actively-running computer program.
Another aspect of the invention provides that no active units of execution are running in the modules when they are being refreshed and further assures that all modules involved are successfully refreshed, or else none of them are (atomic refresh).
Yet another aspect of the invention preserves state information from previous instances of a module and makes that information available to a new instance of the module.
Further aspects of the invention minimize the disruption to a running computer system by not requiring a system shutdown or manual quiesce to replace the modules and by pre-loading and initializing all modules being refreshed prior to stopping access to the previous instances of the modules, and then only keeping the module access blocked for the time it takes to swap in pointers to the new modules into control blocks.
When the present invention is invoked to refresh or update one or more modules on an active computer system, the new module(s) are loaded into memory and initialized or otherwise made ready for execution. This include pointing the new replacement modules to the state data, data structures, etc. already being used by the corresponding existing modules and creating the necessary data structures, data blocks, etc for any absolutely new modules that may be added.
Once the new modules are in a state of readiness, a lock is taken by the refreshing process over execution of the module(s) so that all other processes, threads etc. are no longer executing the existing modules and no new processes, threads, etc. may start executing.
The lock is held only long enough to make the association from the calling point (where threads, processes, etc. gain access to the subject modules) to the new modules instead of the existing or old modules. Any waiting for processing is minimized to this relatively brief moment which has minimal impact.
Finally, the lock is released, execution continues using the new modules, and the old modules are discarded thus freeing up memory resources.